One or more aspects of the invention relate generally to discovering and identifying resource dependencies.
In the IT environment, resources that are part of the environment—e.g., physical computer systems, virtual computer systems, network hardware like switches or applications, software application and/or appliances—referred together as “IT resources”, are typically related through a net of dependencies, resulting from configuration settings and as such are subject to change (typically by human factors). These dependencies are required to be constantly identified, tracked and controlled.
Typically, information about dependencies between IT resources are stored in Configuration Management Database (CMDB) systems as dependencies between Configuration Items (CIs) being representations of the IT resources from the configuration perspective.
A problem with identifying which two CIs are related through a configuration dependency of some type typically consists of two parts: One is related to finding and understanding the configuration of the resource, meaning the ability to discover the resource, read and parse configuration settings and store them in a CMDB as CIs. The second part is related to the ability to detect from the CI's configurations that two or more CIs have a dependency as a result of their configurations, especially in cases where there are ‘proxy’ CIs involved in translation of configurations between a dependency target and source. Such ‘proxies’ may, e.g., be devices translating IP (Internet Protocol) addresses to a DNS (Domain Name Server) address, load-balancers, etc.
Typical solutions to the described problem are based on handling each configuration by specialized, proprietary code strictly tied with a given communication protocol stack, e.g., code being able to understand JDBC (Java Database Connectivity) based dependencies is parsing JDBC connectivity information of an accessing CI's configuration (e.g., a Java application), then trying to match that to RDBMS (relational database management system) servers information—typically a listening interface and ports—and databases available on that server. If a load-balancer is present between a database accessor and an RDBMS server, there is a need to extend the described logic with load balancer aware code which may be based on the load-balancer's configuration which may allow a correlation of connectivity information from the accessor with the RDBMS configuration. There may be multiple types of load balancer's configurations because, typically, the configurations are vendor-specific. Moreover, multiple types of load-balancing techniques exist. The same may apply to configuration settings of different RDBMS vendors and/or multiple configurations of elements (CIs) accessing the databases exposed by the RDBMS.
Thus, such an approach requires separate handling for each accessor type, proxy elements between accessor and accessed CIs, making that solution very hard to extend and maintain.